Cream of the Crop 26

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 26 / Cream of the Crop 26.iso / bbs / mxgui203.zip / MAXDOOR.DOC < prev next >

Wrap

Text File | 1997-08-14 | 36KB | 670 lines

╔═══════════════════════════════════════════════════════════════════════════╗ ║ FIRST THINGS FIRST - READ THE FILE WARNING.TXT BEFORE PROCEEDING! ║ ╚═══════════════════════════════════════════════════════════════════════════╝ ┌╦══╦┐ ┌╦══╦┐ ┌╦═══╦┐ │╠══╩╗┐│╠══╩╗┐└╩═══╦┐ └╩═══╩┘└╩═══╩┘└╩═══╩┘ ┌╦ ╦┐┌═╤╦╤═┐┌═╤╦╤═┐┌╔ ┌═╤╦╤═┐┌═╤╦╤═┐┌╔═══╦┐┌╔═══╦┐┌════╦┐ │║ ║│ │║│ │║│ │║ │║│ │║│ │╬══ │╬══ ┌─╔═╝─┘ └╩═══╩┘ ╧╩╧ └═╧╩╧═┘└╩═══╩┘└═╧╩╧═┘ ╧╩╧ └╩═══╩┘└╩═══╩┘└╚════┘ ┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐┌═╤╦╤═┐┌╦ ╦┐┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐ └╩═══╦┐│║ ║││╬══ │║│ │║ ╦ ║│├╬═══╬┤│╠══╦╩┘│╬══ └╩═══╩┘└╩═══╩┘└╩ ╧╩╧ └╩═╩═╩┘└╩ ╩┘└╩ ╚═┘└╩═══╩┘ <tm> A Subsidary Of LA-Soft ─────────────────────────────────────────────────────────────────────────────── ▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀▀ ▀▀▀▀▀ The DoorKit! ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀ The BBS Door Development Kit By The People - For The People! ─────────────────────────────────────────────────────────────────────────────── The ANSI/ASCII/RIP/MAX DoorKit v1.36 No Copyright Notices Expressed Or Implied Compiled By Larry L. Athey From Numerous Sources ─────────────────────────────────────────────────────────────────────────────── ▀▀▀ ▀▀▀ ▀▀▀▀▀ ▀▀ ▀▀ ▀▀▀▀ ▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀▀ ▀▀ ▀▀▀▀▀▀▀ ▀▀▀ ╔══ ╦═╗ ╔═╗ ╦═╗ ╦ ╦ ╦ ╔═╗ ╔═╗ ▀▀ ▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ║ ╦ ╠╦╝ ╠═╣ ╠═╝ ╠═╣ ║ ║ ╚═╗ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ╚═╝ ╩╚═ ╩ ╩ ╩ ╩ ╩ ╩ ╚═╝ ╚═╝ ─────────────────────────────────────────────────────────────────────────────── The Universal Multimedia Interface For BBS Software Copyright 1995-Current * Larry L. Athey * BBS Utiliteez Software ─────────────────────────────────────────────────────────────────────────────── Information Regarding MAX Graphics: ─────────────────────────────────── Notice is hereby given that the MAXscript/MAXcontrol/MAXcolor language, and MAXterm are products of BBS Utiliteez Software and are protected by US copyrights listed with the US Library Of Congress (1996).... No changes, additions, subtractions, or other modifications shall be made to MAXscript/MAXcontrol/MAXcolor language or the MAX Graphics development kit without express written permission from Larry L. Athey, BBS Utiliteez Software, Alliance, Nebraska, USA.... The MAXscript/MAXcontrol/MAXcolor language may be used in any BBS or Door software 100% royalty free. You are also allowed to implement full local graphics viewing in any BBS or Door software 100% royalty free. However, any program that uses the MAXscript/MAXcontrol/MAXcolor language *MUST* bear the MAX Graphics/BBS Utiliteez Software copyright notice.... Example: MAX Graphics and the MAXscript/MAXcontrol/MAXcolor language is (C) 1995-Current * Larry L. Athey * BBS Utiliteez Software Disclaimer: ─────────── MAX Graphics, MAXscript/MAXcontrol/MAXcolor and MAXterm are by no means copies of, or otherwise plagiarized remote graphics methods used by any other BBS software. Even though MAXterm responds to a few commands used by RIPscrip and other RIP capable BBSes, this is by no means any kind of a copyright infringement of the RIP technology. If it was, then I'm sure that Pat Clawson of TeleGrafix would have notified me by now.... Yes, there are some similarities between MAX Graphics and some other BBS graphical user interfaces, yet this is still not any kind of a copyright infringement either. Since I have ran about every graphical BBS out there from DOS to Windows platforms, I'm bound to create things in the image of my own memory. Even the authors of other graphical BBS packages have told me where they got their ideas....Other graphical BBS packages....So don't worry if someone tells you "Gee, your BBS looks a lot like Shotgun BBS or RoboBOARD/FX", all similarities if any are 100% within copyright laws.... ....End of disclaimer.... ─────────────────────────────────────────────────────────────────────────────── The Contributors: ───────────────── This is a list of people who contributed to the cause of beta testing the MAX Graphics related programs and the TDK door development kit. Although there were more people who applied to be beta testers, most of these beta sites never posted anything in the support echo, so I don't consider them to have made any contribution to the cause. But, these people stood by me and my efforts without a single sour word, and never threw in the towel.. Many people apply to be a beta tester for new programs and never think of the qwerks involved in testing untested software. So they quickly give up and avoid beta testing like the plague. Beta testing requires a person to do nearly as much work (if not actually more) as the programmer themself. Programs can't evolve without testers actually running the program and at least trying to make it work even with the bugs in it. True beta testers don't seem to know the meaning of the phrase "I give up", and that's what makes being a program author worth while. I couldn't give a damn if I get one more program registration in my life, so long as there are dedicated common sense thinking people like this standing by you, it's worth while! Let's here it for the people that refused to say "I give up"! Name: BBS: Phone: ─────────────────────────────────────────────────────────────────────────── Brad Larned (1:205/400) The Fresno Online BBS 209-276-3657 Sean Price (1:205/46) Sanctuary From The Law BBS 619-377-3611 Chris Martin (1:219/308) The Mars Station BBS 760-254-3012 Bob Wingender (1:284/11) The Oak Tree BBS 417-581-0868 Chet Rhodes (1:151/124) Hawkmoon's Realm 919-556-8363 Larry Thrasher (1:3612/650) The Night Thrasher BBS 904-937-9144 Thomas Wells (1:3621/1) Renegade's Hideout 615-326-5597 Timothy Barney (1:2622/3) The Gravel Pit 814-942-1552 Cliff Williams (1:112/124) The City Of Thought 904-645-8850 Jon Parise (1:2606/421) Infinite Twilight 908-637-8243 Arthur Stark (1:395/670) Top's Diamond Mine 254-542-8783 Ronald Schlegel (1:110/1065) Dynasty BBS 937-258-1030 David Raasch (1:280/285) Let It Shine Online! 816-461-2290 ─────────────────────────────────────────────────────────────────────────── NOTE: These names appear in no particular order, they are only listed here as the names appear in my MAX Graphics area message base... ─────────────────────────────────────────────────────────────────────────────── The Golden Rule Of Writing TDK MAX Doors: ───────────────────────────────────────── First of all, before you even attempt to write a TDK MAX door, or a MAX door with any other door development kit, read MAXINFO.DOC in its entirety so you understand exactly how MAX Graphics works. Don't be scared of this rule, you will see that using the MAX language is almost identical to using Pascal, so you will definitely be able to grasp this concept with no problems at all... It is imperative that you fully understand how MAX Graphics and MAXterm work with each other before you attempt to write a MAX door...If you just jump in to this thing head first without looking ahead of time, chances are that you will end up injuring your head. Most likely from banging your head against a wall trying to figure out why something isn't working like you want it to... MAX Graphics is totally unlike RIP...You can actually learn MAX and memorize it just like a programming language...The most important thing about writing a MAX door is to not allow yourself to be initimidated, you are only writing a program to send text to the remote. All of the low level stuff is actually handled by MAXterm...So don't be scared, and don't make things hard, because you now have a way of making SVGA doors just as simple as if you were making a plain old ANSI/ASCII door... ─────────────────────────────────────────────────────────────────────────────── About The MAXDOOR Archive: ────────────────────────── This archive contains sample source code to show the principals of writing MAX compatible doors. This document is not a replacement for MAXINFO.DOC, so be sure you read that sucker over and over until you have bad dreams of little MAX commands attacking you in your sleep... :) What follows here are special considerations to keep in mind about the concepts used in the MAXDOOR.PAS sample program, in the order they appear in that program... ─────────────────────────────────────────────────────────────────────────────── Displaying MAX Screen Files With TDK: ───────────────────────────────────── Regarding DOORKIT3.PAS / PROCEDURE ShowScreen(Scr : STRING); You don't have to do anything special in your doors to display screen files with TDK. MAX screen files don't even need to have the ASCII #12 in them to clear the remote screen because TDK automatically sends it if it detects a user is running MAXterm. If TDK detects MAXterm, all MAX screen commands are sent directly to the comport rather than being scrolled up the screen. When MAXterm is detected, a simple banner is printed at the bottom of the screen telling you that it is displaying the screen file to the remote. This looks better than having a bunch of garbage commands rolling about the screen. TDK also does the same thing in the event of RIP and AVATAR callers as well... If you want to have more than one MAX window on the screen at once, you can tell TDK not to send the ASCII #12 to kill the screen. There is a variable in TDK called "NoKill". If you make a call to "NoKill := TRUE;" before you display a MAX screen file, and so long as your screen file itself does not contain an ASCII #12 or Start_Screen() command at the beginning, the screen file contents will overlap the previous screen. In this case, you will want to make sure that your screen starts with a Hide_Mouse() command, and that you insert a Show_Mouse() command before the End_Screen() command... ─────────────────────────────────────────────────────────────────────────────── Displaying Text Files With TDK: ─────────────────────────────── Regarding DOORKIT3.PAS / PROCEDURE ShowTextFile(TextFile : STRING); Displaying a text file to a MAXterm user can be done in two ways, you can either use the built in text file reader in MAXterm, so long as your text file contains no more than 800 lines. Or, you can use the procedure in TDK to display a text file of unlimited size. The main advantage to using the text file displaying procedure in TDK is that unlike the text file viewer in MAXterm, the text file doesn't need to first exist on the user's system in the ?:\MAXTERM\SESSION\ subdirectory... The ShowTextFile procedure in DOORKIT3.PAS simplifies displaying text files to the remote caller no matter what terminal emulation they support. In MAX Graphics mode, this procedure sends a list of commands to draw a text file reader on the screen with buttons at the bottom for scrolling through the file. All Hide_Mouse() and Show_Mouse() procedures are handled automatically All you do is tell the procedure the path and file name of the text file and that's it. You may still use MAXterm's internal text file viewer with a TDK MAX door if you wish. However, you will have to write the commands into your program to read the text file and send it using the Start_Text_File, Put_Text_File, and End_Text_File MAX commands. It's up to you how you want to do things, I just added the ShowTextFile procedure in TDK to simplify things for you... ─────────────────────────────────────────────────────────────────────────────── Sending Actual MAX Commands To The Caller: ────────────────────────────────────────── Regarding MAX_UNIT.PAS / PROCEDURE MaxCommand(S : STRING); This procedure is included in TDK to help automate and simplify the sending of MAX commands, and handle any return data that certain MAX commands make MAXterm return to your program. As you know from reading MAXINFO.DOC, there are some MAX commands that make MAXterm kick back data to your program, so you need a way of handling this data. What would be great is if there was a way to handle this data in a simple kindergarten level manner. Well, that's what this procedure does. Any time MAXterm kicks back any data like that, the MaxCommand procedure will write this data to text files in the current program directory. All text files use file names that are node specific so as to prevent interference with the same program running on other nodes... You may send MAXscript, MAXcontrol, and MAXcolor commands with MaxCommand, all commands are sent with a carriage return & line feed combination at the and, so you don't have to worry about adding a #13#10 at the end of them... What follows below are various examples of how the MaxCommand procedure is used in a TDK MAX door, and how any return data is handled and stored... ─────────────────────────────────────────────────────────────────────────────── Special Considerations Regarding MAX Entry Fields: ────────────────────────────────────────────────── When writing MAX doors, there are some things you need to keep in mind about the way MAXterm works. One thing you will probably think is ass backwards is that ALT keypresses in MAXterm actually work over the modem. Well, I should say that they "Partially" work, MAXterm doesn't send the initial ASCII #0 or NUL character, it only sends the secondary extended scan code. This is done this way because there are certain internal features in MAXterm that use ALT keypresses and normal keypresses at the same time... Take the entry fields for example. Users type things as normal in an entry field, and if there are more than one entry field on the screen, the <TAB>, <ENTER> and arrow keys scroll through the fields. Well, you need a way to get out of the entry fields and tell the door that you are out of them...So, this is why the ALT keypresses actually work over the modem. Unlike straight ANSI/ASCII doors written with TDK, when you use entry fields with MAXterm, all the work is actually done within MAXterm itself. Things are done in this way because it eliminates the need to keep a constant flow of ANSI escape sequences running back and forth, thus resulting in a faster and smoother operation for both programs at the same time... In the example MAXDOOR.PAS program, you will see that the entry field demo looks for an ASCII #24 to tell the door to query MAXterm for the text that the user typed in the entry fields. The FDEMO.MAX screen has two buttons in it, one assigned to an ALT-O (ASCII #24) for "Okay", and the other assigned to ALT-Q (ASCII #16) for "Quit"...Both buttons are assigned to and ALT key so the user can escape the loop in MAXterm that runs the entry fields, and the ordinal value assigned to each button is sent back to your door so you can trap it in the program and handle the required procedures... Querying MAXterm For Entry Field Data: ────────────────────────────────────── In the example MAXDOOR.PAS program, you will see that the entry field demo uses the MaxCommand procedure to force MAXterm to kick back the contents of all the entry fields in the current window. As you know by reading the file MAXINFO.DOC, every MAX command has two versions. One MAXscript command that is humanly readable, and the MAXcontrol counterpart that really isn't that readable. I prefer to use MAXcontrol for everything because it's faster and I seldomly ever have to read through my screen files. If I do, then I just load up the screen in MAXpaint and read it that way... In the example program I use the Get_Field_Data command to tell MAXterm that I need the text from all of the current entry fields to be sent back to me. When you make a call to the procedure MaxCommand('Get_Field_Data()'); or MaxCommand(#255#126#250#255); special procedures are automatically taken care of for you by the MAX_UNIT.PAS unit to obtain the entry field text... The text from each entry field in MAXterm will be written to a file on your hard drive. The file name is FIELDS.### where the ### represents the current node number (ie: FIELDS.1 through FIELDS.255). The text is written to this file in the same order that the entry fields are plotted on the screen in MAXterm. After you send the Get_Field_Data command, simply look for the text file on the hard drive in the current directory. If the file exists, then the transfer of field data was successful, and you can now read the data out of the text file, then apply it to your door as needed... ─────────────────────────────────────────────────────────────────────────────── Special Considerations Regarding MAX PickLists: ─────────────────────────────────────────────── As you probably know, the little "ANSI LightBar Menu" feature in some BBSes is just the coolest thing in the world to some sysops. I find it boring and a waste of time because a single keypress accesses a menu function faster.. But, for those people that like the LightBar effect, there is a feature in MAX Graphics to allow something similar. This is called a "PickList" in MAX Graphics and they work similar to the scrolling selection menus in Windows or OS/2. You can have a little box on the screen that only shows ten items in it at once, but it can actually have up to 800 items to choose from. The items scroll through the little box with a highlight bar which is used for selecting an item in the picklist. You can use your mouse to select/scroll the items, your arrow keys, your Page-Up/Page-Down keys, or a combination of CTRL-Page-Up/CTRL-Page-Down to jump to the top or bottom of the picklist. PickLists must be initialized, stuffed, and activated in exactly that order. An example of this would be: New_PickList(100,100,3,30) {PickList Initialization} AddTo_PickList('Item #1') {PickList Stuffing} AddTo_PickList('Item #2') {" "} AddTo_PickList('Item #3') {" "} AddTo_PickList('Item #4') {" "} AddTo_PickList('Item #5') {" "} SetUp_PickList() {PickList Activation} This sequence of MAX commands (excluding the {Comments}) initializes a new picklist on the screen at the coordinates 100/100. The picklist only allows 3 items to to appear on the screen at any one time, and the picklist allows up to 30 characters of each item to display on the screen. Now, even though only 3 items are displayed at any one time, the picklist actually contains 5 items that will scroll through the picklist field on the screen... It is critical that you execute these commands in the order that they appear in the above example, the reason for this is fully detailed in MAXINFO.DOC.. You may have up to 800 AddTo_PickList(' ') commands in the screen file, so a picklist can really be HUGE, but only have a small fraction of items on the screen... The SetUp_PickList() command is what actually draws out the picklist items on the screen. Let's say that you wanted the picklist to default to another item besides number 1 when it is activated. You can do this by a call to the Reset_PickList() command before the SetUp_PickList() command. Say that your picklist has 500 items in it, and you want it to always default to item 250 when it draws. Simply insert a Reset_PickList(250) before SetUp_PickList... The most important thing to keep in mind about picklists is that they MUST appear in the screen before any other buttons. This is because the buttons in the picklist are automatically assigned to buttons number 1 and 2. This is something you will never have to worry about if you make your screens in MAXpaint, because it has built in intelligent MAX syntax checking. However, if you are manually writing your screens just as if you were using graphics commands in a programming language, you have to make sure that you get the commands in the screen in the correct place, and in the correct order... Detecting The Selected PickList Item: ───────────────────────────────────── Now that you know how to properly place a picklist on the screen, how does a person tell when the user selects an item, and which item is selected? This is just as simple as obtaining the field data mentioned in the above. If you look at the picklist example code in MAXDOOR.PAS, you'll see that things are done the same way. Meaning, you check for ALT keypresses and tell MAXterm to send data back that is written to a text file on your hard drive... In the example code, the screen file containing the picklist uses an ALT-S keypress assigned to a button labeled "Select" in the screen file. When the button is clicked, or when the user presses ALT-S, MAXterm will return an ASCII #31 to your door. If you receive an ASCII #31, then you know that you need to use the MaxCommand procedure to tell MAXterm to report which item in the picklist has the highlight bar on it. Again, there are two different commands that will tell MAXterm to send back this information: MaxCommand('Get_Pick_Info()'); { MAXscript Get_Pick_Info } MaxCommand(#255#126#247#255); { MAXcontrol Get_Pick_Info } When MAXterm sends the information back, you will end up with a file on the hard drive in the current directory. The file name is PICKINFO.### where the ### represents the current node number (ie: PICKINFO.1 thru PICKINFO.255)... In this text file, there will be two lines of text. The first line will show the actual number of the selected picklist item, and the second line will be the actual text string of the selected picklist item. Once you have the file on your hard drive, you just read the file and apply the data to your door as needed... ─────────────────────────────────────────────────────────────────────────────── Using MAXterm Text View Ports: ────────────────────────────── The use of Text View Ports in your doors can help you cut down your program overhead in a major way because it allows you to share the same text output routines that your door's ANSI side uses in the door's MAX side as well... If you look at the Text View Port Example in MAXDOOR.PAS, you will see that it uses the OutTxt procedure to print the text just like you would use in an ANSI/ASCII door. Another thing is that even though there is active graphics on the screen (meaning anything changing after the window is drawn) text in the port will not cause "Mouse Warts" on the screen if the mouse happens to be within the port while the text is drawing. This is all handled within the terminal program, so there is no need to send a bunch of mouse hide and show commands to the remote... Also, as a review note...Text View Ports can be up to 79 columns wide, and up to 25 rows high. You can essentially draw a full size ANSI screen within a Text View Port if you wish to... ─────────────────────────────────────────────────────────────────────────────── Internal Screen Files: ────────────────────── If you don't want to have a bunch of separate screen files lying around the hard drive, you can easily put your screen files right into your program... The MAXTOPAS.EXE utility will read a MAX screen file and create an include file that you can link into your program. The screen file will be converted to an individual procedure. If your screen file is MAINMENU.MAX, the utility will read the file and create a procedure called Mainmenu_Max in a separate include file (MAXTOPAS.INC)...Simply add a {$I MAXTOPAS.INC} in your program and call the procedures as needed. Every time you run MAXTOPAS.EXE, it will look for the MAXTOPAS.INC file. If it doesn't exist, it will be created, if it does exist, all screens will be appended to the end of the file... You will most likely want to overlay the unit that calls these procedures because it will end up taking a big hunk out of the conventional memory if you have a lot of internal screen files. If you overlay them, then they will be held in XMS, EMS, or in the overlay on the disk. All of this is handled automatically by the OVERXMS.PAS unit. Be sure to keep backup copies of your screen files in the event you want to change them in the future. Also, you will have to save your screen files with the ASCII #12 in them before they are converted if you don't want screens to constantly overlap each other... See the file MAXDOOR.INC and how the file is linked into MAXDOOR.PAS for a clearer idea of how all of this works... HEY - THIS IS IMPORTANT! ──────────────────────── You don't have to include full icon libraries with your doors. If your door only uses two or three icons, you can chop the library down so there are only the required icons for your door included in the library. Doing this also protects your icons from being modified because neither MAXpaint, or the icon editor in the MAXterm Plug-Ins will load an icon library unless it has 100 icon records in it... Below is a basic example of how you can chop any icon library down to size for use with your door. When a door displays an icon, all you do is seek to a specific record location, so just put all of your icons at the beginning of the icon library and never try to seek past the highest record number. It also makes for a much faster transfer of your icons in resource updates. {$A+,B-,D+,E+,F+,G+,I-,L+,N-,O+,P-,Q-,R-,S-,T-,V+,X+} PROGRAM ICONCHOP; {This code is courtesy of Brad Larned / FzSoft} USES CRT,DOS; TYPE Icon16x16 = RECORD Matrix : ARRAY[1..16,1..16] OF BYTE; END; TYPE Icon30x30 = RECORD Matrix : ARRAY[1..30,1..30] OF BYTE; END; TYPE Icon60x60 = RECORD Matrix : ARRAY[1..60,1..60] OF BYTE; END; VAR I16 : Icon16x16; Dat16 : FILE OF Icon16x16; D16 : FILE OF Icon16x16; I30 : Icon30x30; D30 : FILE OF Icon30x30; Dat30 : FILE OF Icon30x30; I60 : Icon60x60; D60 : FILE OF Icon60x60; Dat60 : FILE OF Icon60x60; FName1 : STRING; FName2 : STRING; Stop : BYTE; Count : BYTE; {───────────────────────────────────────────────────────────────────────────} FUNCTION StrToInt(S : STRING) : LONGINT; VAR L : LONGINT; U : INTEGER; BEGIN VAL(S,L,U); StrToInt := L; END; {───────────────────────────────────────────────────────────────────────────} FUNCTION Exist(Filename : STRING) : BOOLEAN; VAR Inf : SEARCHREC; BEGIN FINDFIRST(Filename,AnyFile,Inf); Exist := (DOSERROR = 0); END; {───────────────────────────────────────────────────────────────────────────} { ICONCHOP.EXE OldFile Newfile Count } { Paramstr(1) = Current Icon Library Name } { Paramstr(2) = New Icon Library Name } { Paramstr(3) = New Icon Count - Cut here } BEGIN IF PARAMCOUNT = 3 THEN BEGIN FName1 := PARAMSTR(1); FName2 := PARAMSTR(2); Stop := StrToInt(PARAMSTR(3)); IF (Stop = 0) OR (Stop > 100) OR (NOT Exist(FName1)) OR (FName1 = FName2) THEN HALT; Count := 1; IF POS('.001',FName1) > 0 THEN BEGIN { 16 x 16 Icon Sets } WRITELN('16 x 16 Icon Library Detected...'); ASSIGN(Dat16,FName1); ASSIGN(D16,FName2); RESET(Dat16); REWRITE(D16); WHILE (NOT EOF(Dat16)) AND (Count <= Stop) DO BEGIN INC(Count); READ(Dat16,I16); WRITE(D16,I16); END; CLOSE(D16); CLOSE(Dat16); END ELSE IF POS('.002',FName1) > 0 THEN BEGIN { 30 x 30 Icon Sets } WRITELN('30 x 30 Icon Library Detected...'); ASSIGN(Dat30,FName1); ASSIGN(D30,FName2); RESET(Dat30); REWRITE(D30); WHILE (NOT EOF(Dat30)) AND (Count <= Stop) DO BEGIN INC(Count); READ(Dat30,I30); WRITE(D30,I30); END; CLOSE(D30); CLOSE(Dat30); END ELSE IF POS('.003',FName1) > 0 THEN BEGIN { 60 x 60 Icon Sets } WRITELN('60 x 60 Icon Library Detected...'); ASSIGN(Dat60,FName1); ASSIGN(D60,FName2); RESET(Dat60); REWRITE(D60); WHILE (NOT EOF(Dat60)) AND (Count <= Stop) DO BEGIN INC(Count); READ(Dat60,I60); WRITE(D60,I60); END; CLOSE(D60); CLOSE(Dat60); END; WRITELN; WRITELN('All Done, New Icon Library ',FName2,' length set at (',Stop,') Icons ..'); WRITELN; END ELSE WRITELN('ICONCHOP.EXE OldFile Newfile Count'); END. ─────────────────────────────────────────────────────────────────────────────── Implementing MAXecutables: ────────────────────────── MAXterm is also capable of a very special feature which allows you to write doors that also run on the user's system. These are referred to as (what I call) a MAXecutable file. These are special executables that run in MAXterm's \SESSION\ subdirectory. These executables are called with MAXterm's program home directory as the only command line parameter. MAXecutables must also read the \MAXTERM\SESSION\MAXINFO.DEF drop file, this is a custom drop file that is created every time MAXterm receives the MAXecute() script command. Here is how MAXecutables work with MAXterm: 1. A MAXecutable is a standard executable file with the exception that it has to be run in the \SESSION\ subdirectory of MAXterm. You can still run them locally by feeding them false information in their start up files, this is needed for development. A MAXecutable is designed to read a MAXINFO.DEF drop file to get all of the required communications parameters, user name, etc. 2. When you send the MAXecute('FILENAME.EXE') command, MAXterm will do this: (a) Write a MAXINFO.DEF drop file in the \SESSION\ subdirectory. (b) Close the comport while leaving the DTR hot. (c) Shut down the graphics mode (ie: RestoreCrtMode;). (d) Change to MAXterm's \SESSION\ subdirectory. (e) Execute FILENAME.EXE with MAXterm's home directory as ParamStr(1). (f) Change back to the MAXterm home directory. (g) Restart the graphics mode (ie: SetGraphMode(GetGraphMode);). (h) Restore the previous SVGA screen. (i) Re-open the comport. (j) Send an ASCII #13 to the comport indicating a successful return. 3. While the MAXecutable is running, you have 100% control over everything, MAXterm is no longer active in any way whatsoever. So it is completely up to you to monitor for carrier, inactivity timeouts, etc. This also means that you can now do things that are impossible within the constraints of the MAXscript/MAXcontrol/MAXcolor language. You could theoretically run a program of any other graphics resolution, the TDK and UltraBGI kits are by no means required for MAXecutables. Technically, a MAXecutable is simply a remote operated door. It's not rocket science, it's simply a way of giving door programmers unlimited possibilities and total freedom of program design. When writing MAXecutable programs, you need to look at things kind of backwards. The remote system actually becomes the host in a sense. Just like any standard ANSI terminal, MAXterm doesn't know anything about how much time a use has left. So you will need to make some type of a "Server" program that runs as a door off of the BBS. This may be needed to transfer the actual MAXecutable from the BBS to the remote, and absolutely will be required to get any information about the user from the BBS to the remote. There are no standardized commands or methods to do this, so the server is an absolute must. The server may also be needed to send and receive score data files or other critical system related files. The MAXINFO.DEF Drop File: ────────────────────────── When a BBS or a door send the MAXecute command to your terminal program, it will create a special drop file for the MAXecutable program to read...Below is a line by line definition of the MAXINFO.DEF system drop file: 1. The user's name stored in the current dialing directory entry. 2. The user's password stored in the current dialing directory entry. 3. Use SoundBlaster: "TRUE" or "FALSE" (without quotes). 4. Current .PKG file name in use with no .PKG extension. 5. Program upload path. 6. Program download path. 7. System archiver path. 8. System default archiver (1=ZIP, 2=LHA, 3=ARJ, 4=RAR, 5=Custom). 9. Custom archiver batch file name. 10. Custom unarchiver batch file name. 11. Custom external protocol upload batch file name. 12. Custom external protocol download batch file name. 13. Current comport in use (1 to 8). 14. Current comport hex address (0 for standard address). 15. Current comport IRQ (0 for standard IRQ). 16. Current comm device (1=UART, 2=Fossil, 3=DigiBoard). 17. Current comport port speed (ie: locked port rate). 18. Current connection speed (ie: caller's actual baud rate). 19. Current comport input buffer size in bytes. 20. Current comport output buffer size in bytes. 21. Using hardware flow control: "TRUE" or "FALSE" (without quotes). 22. Modem initialization string #1. 22. Modem initialization string #2. 22. Modem initialization string #3. 23. Modem answer string. 24. Modem on hook string. 25. Modem off hook string. 26. Modem dialing string. NOTE: MAXterm only uses 8-N-1 communications....If I was interested in any kind of 7 bit communications stuff or any internet programming, this archive would say that is was from "Internet Utiliteez Software".... ─────────────────────────────────────────────────────────────────────────────── ┌───────────────────────────────────────────────────────────────────┐ │ │ │ ┌── ┌────── ┌────── ┌────── ┌────── ┌──────── │ │ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │ │ ┌── ┌──────── ┌──── ┌────── ┌── ┌── ┌──── ┌── │ │ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │ │ ┌────── ┌── ┌── ┌────── ┌────── ┌── ┌── │ │ │ └───────────────────────────────────────────────────────────────────┘ Not just software....It's a computer enhancement! ┌───────────────────────────────────────────────────────────────────┐ │ Contact: 1:14/703@FidoNet Or: USA MAX Graphics HQ-BBS │ │ 411:1500/0@ivNET (308)762-2239 │ │ 121:101/2@AllianceNet FAX or Data Calls │ │ maxgfx@juno.com ANSI/ASCII/MAX (No RIP) │ └───────────────────────────────────────────────────────────────────┘ ───────────────────────────────────────────────────────────────────────────────